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ABSTRACT 



In an unprecedented globally competitive market, industry 
demands an electronic mail or messaging system that will 
transport all forms of data. The Consultative Committee for 
International Telegraphy and Telephony (CCITT) X.400 family of 
standards is a messaging transport standard that facilitates 
international message exchange. Combined with an appropriate 
network architecture, the series provides a complete package 
for transport of electronic objects such as digitized voice, 
documents, forms, graphics, images, spread sheets and text. 
The purpose of this thesis is to provide DoD technicians and 
managers, who will be utilizing X.400-based E-Mail within the 
Defense Message System (DMS) , with a thorough discussion of 
the X.400 standards. Highlighted by industry examples, 
possible, conceptual solutions for incorporating the standards 
into existing electronic messaging environments are provided. 
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I. 



INTRODUCTION 



A . BACKGROUND 

Although the Department of Defense (DoD) has had an 
electronic messaging infrastructure since the late 1960s, with 
the inception of the Automatic Digital Network (AUTODIN) , 
there is a new architecture under procurement called the 
Defense Message System (DMS) . 

This DMS infrastructure will support both organizational 
and individual messaging. The current infrastructure, or DMS 
baseline, consists of distinctly separate , "individual" and 
"organizational" messaging components. Organizational 
service is provided by the AUTODIN, and individual service is 
provided by electronic mail applications on the DoD Internet. 

The DMS Program is the result of a 1988 Assistant 
Secretary of Defense (ASD/C3I) effort to determine the future 
of DoD electronic messaging systems. The areas that mandated 
change were: (1) problems and costs associated with managing 
the baseline system, (2) lack of an overall DoD messaging 
architecture, and (3) emergence of new international standards 
and technology-mandated change. (DoD 1993, p.7) 

The need to interconnect and interoperate has driven DoD, 
as well as civilian corporations, to develop international, 
standard-compliant systems. Organizations need to exchange 
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messages with its components, clients, and competitors across 
the boundaries of the proprietary electronic mail packages 
they may use. X.400/X.500 protocols are one means to make 
this interconnection happen. 

B. PURPOSE AND SCOPE 

The purpose of this thesis is to provide DoD technicians 
and managers alike who are associated with an E-Mail system, 
a basic, thorough discussion of the Consultative Committee for 
International Telegraphy and Telephony (CCITT) X.400 family of 
Message Handling Standards. Additionally, a brief definition 
of the associated CCITT X.500 Directory standard is provided. 
Since many corporations have already invested significantly in 
various E-Mail packages, specific platforms and operating 
systems, a global messaging standard that transparently unites 
all disparate E-Mail systems would be ideal. X.400 and it's 
directory counterpart, X.500 are CCITT recommendations for 
this evolutionary messaging demand. This thesis topic has 
direct application to DoD since it specifically discusses 
X.400 implementation issues for the E-Mail portion of the 
Defense Message System (DMS) . In the conclusive chapter, 
after identifying industry lessons learned on an X.400 
installation, possible solutions are given for DoD components 
on how to incorporate X.400 into their electronic messaging 
environment. These conceptual solutions may assist 
Information Technology managers in planning their messaging 
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systems so that they may have the message handling 
functionality of the standards in the interim period of the 
X.400-based DMS implementation. 

The scope of this thesis includes: discussion of the 
evolution of the CCITT X.400 standard series; a description 
of how it works; issues from a product review and Corporate 
Computing's ZD Labs' report; a look at how the DMS Program 
plans to implement X.400; and a snapshot of how Wal-Mart 
Stores Inc. is currently implementing a company-wide, X.400 
messaging system. 

C. EVOLUTION OF X. 400 /X. 500 PROTOCOLS 

"Electronic messaging can perhaps be said to 
have started around the time when, in 1851, 
the New York and Mississippi Valley Printing 
Telegraph Company (later renamed as the 
Western Union Telegraph Company) was founded. " 

(Betanov 1993, p.2) 

Led by this giant, common-carrier, Western Union Telegraph 
Company, message switching functionality was provided in a 
torn tape manner over telegraph lines that were usually 
dedicated. It wasn't until a hundred years later, in the 
1960s and 1970s, that this message switching functionality was 
provided via computers . This enabled private organizations to 
assemble their own messaging networks by leasing dedicated 
circuits from carriers and interconnecting them using 
computers acting as switches. These switches were often 
connected to the telex network which had been in operation 
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since the 1930s. The telex market was dominated by 
organizations like large banks and trading companies with 
international operations as well as industry groups with 
international scope. 

Another related development in the 1960s and 1970s was 
that of general-purpose, packet switching networks. These 
networks primarily facilitated the task of communicating data 
to and from computers. The first significant packet switching 
network was the ARPANET, sponsored by the Advanced Research 
Projects Agency. Between 1969 and 1977, ARPANET grew from 4 
nodes to 111 hosts. Within packet switched networks, the 
transmission protocols had to be separated from the messaging 
and other application protocols since messages were decomposed 
into packets and sent packet by packet instead of as one whole 
entity. This division in functionality created independent 
development of both application and transmission protocols. 
Thus, software development for these protocols and integration 
of packet switching technology into applications were 
simplified. The person programming the application did not 
have to know details of packet switching mechanisms. The 
developer just had to know how to use the Application Program 
Interface (API) . The Consultative Committee of International 
Telegraphy and Telephoney's (CCITT) eventually provided formal 
recommendations, called X.25 and X.75 that represented packet 
switching. The major result of these protocols was to allow 
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easy interconnection of dissimilar systems regardless of 
hardware platform. (Betanov, 1993, pp.3-4) 



From the perspective of electronic mail applications and 
services, the customized development of X.25 applications 
resulted in two basic problems: (1) hardware manufactures 

developed electronic mail applications that operated only on 
platforms that they manufactured such that they were not 
compatible with those developed by another manufacturer; and, 
(2) electronic mail service providers allowed users access to 
their systems for sending and receiving messages. For example. 
Western Union provided Easylink service, MCI provided MCIMail 
and Sprint provided Telemail. However, these carriers offered 
no connectivity among themselves except through telex; 
therefore, the services were strictly proprietary. The 
following situations highlight these developmental problems: 
(Betanov, 1993, pp . 4-5) 

• An organization using equipment from different hardware 
manufacturers could not easily connect E-mail systems 
running on the various platforms. 

• An organization could not readily connect its proprietary 
E-mail system to a public E-mail system provided by a 
common carrier or service provider. 

• Users of various public E-mail systems by different 
service providers were basically isolated from one another 
since these disparate systems had no interface with one 
another . 

Customized interface solutions to the above problems 
evolved for interconnecting different hardware and software. 
Without a standardized solution, the interface-building wheel 
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was reinvented over and over again, users were very frustrated 
and businesses spent a lot of money. 

Industry began to demand a messaging environment that 
would provide common functionality across hardware platforms 
and service providers. If the definition of such an interface 
could be achieved, not only would it become as easy to 
interconnect electronic mail systems as it is easy to 
interconnect dissimilar systems using X.25, but it would also 
be possible to develop standardized applications that could be 
invoked using APIs. Theoretically, an API would remove the 
requirement that a programmer know all the details of message 
handling in order to incorporate messaging into an 
application. A program could be written to "pass" the message 
contents and selected service elements (ie., recipients 
address) to the API and the E-Mail system behind the API would 
then handle the specific details of ensuring the message was 
received at the destination. 

Development of a generalized messaging system was 
initiated in 1975 when the United Nations Educational 
Scientific and Cultural Organization (UNESCO) organized 
"Working Group 6.5" through it's subcomponent, the 
International Federation of Information Processing (IFIP). 
The overall mission was to develop the requirements for a 
computer-based messaging system. In 1981, another organization 
within the UN, CCITT, which was mentioned earlier, followed on 
IFIP's work. In 1984, the CCITT X.400 series of recom- 
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mendations governing message handling systems were ratified. 
(Betanov, 1993, pp . 5-6) 

By December of 1988 service providers did not appear too 
anxious to change their proprietary status quo. Providers of 
public E-mail services developed X.400 messaging capability 
but were not aggressive to interconnect their respective 
systems. In response, an industry group called the Aerospace 
Industry Association (AIA) , which happened to be a very large 
customer of the E-mail industry, invited all major E-mail 
providers in the U.S. to participate in a pilot project. 
Essentially, all providers were to connect their respective E- 
mail systems via X.400 to demonstrate the feasibility of X.400 
connectivity. This AIA pilot project was extremely successful 
in that all providers were able to establish connectivity to 
at least one other service provider despite their extremely 
different implementations and hardware platforms. (Betanov, 
1993, pp. 6-7) 

In response to industry demands as well as the CCITT 
normal four-year review cycle for standards, X.400 was 
reviewed, improved (ie., more readable and secure, better 
interfaces, and a new message store functionality) and 
completely re-written for ratification in 1988. 

1988 also documented the adoption of a series of CCITT 
recommendations for a directory system, called X.500. Many of 
the CCITT committee members who developed the 1988 X.400 
protocols helped develop this new set of protocols (Radicati, 
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1994). Used in conjunction with X . 400 -compliant messaging, 
the X.500 recommendations proposed simplification of the 
address determination and related issues in X.400 
environments . 

During 1990, the U.S. -based service providers became fully 
interconnected so that a user of any public E-mail service 
could communicate with a user of any other public E-mail 
service. In fact, by June of 1992, many of the service 
providers had links to providers located in 20 to 40 other 
countries. In the 1990-1993 time frame, the following 

additional but related developments occurred: (Betanov, 

1993, pp. 8-9) 

• The number of systems providing X.400 interfaces increased 
sharply. For example, most E-mail packages running on 
local area networks (LANs) provide X.400 gateways which 
interconnect individual LANs and other messaging systems. 
This creates either a corporate electronic messaging 
backbone using X.400, or X.400 LANs connected to a service 
provider's public E-mail system. 

• February 1990 - the North American Directory Forum was 

created to accelerate the development of a global X.500- 
compliant directory system. 

• June 1991 - CCITT promulgated the X.435 standard , which 
allows for the exchange of electronic data interchange 
(EDI) documents over X.400 networks. 

• February 1992 - a U.S. -based vender of X.400 products 

announced a suite of products that allow X.400 connections 
over telephone lines, as opposed to packet network 
connections. This development reduces the cost of 
maintaining X.400 connections allowing smaller user 
communities to become integrated into the global X.400 
network, thus increasing the user base reachable via 
X.400 . 

• October 1992 - X.400 Application Program Interface 

Association (XAPIA) is a well-established, standards- 
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setting organization composed of the major E-mail vendors 
who have created a set of APIs to the X.400 messaging- 
service standards. The association is also working on a 
set of cross-platform messaging APIs that will further 
enhance the functionality of X.400 (Duffy, 1992, p.S/25). 

• June 1993 - Many major vendors are providing native, or 
2nd generation X.400 implementations which are real, E- 
mail, backbone environments that comply with the 1988 
X.400 standard as opposed to 1st generation 1984 X.400 
"mapping" products like proprietary X.400 gateways 
(Radicati, 1994) . 

• September 1993 - Department of the Air Force publishes its 
Request for Proposal for the DMS-GOSIP Program specifying 
X.400/X.500 as mandatory requirements for the Messaging 
system (DoAF, 1993) . 



D. ORGANIZATION 

Chapter II characterizes the basic requirements for any 
X.400/X.500 enterprise system. Chapter III will provide 
X.400 implementation methods and issues with an overview of an 
industry lab report from ZD Labs of Corporate Computing. 
Chapter III also identifies the top three industry E-Mail 
packages as well as those used in DoD. Chapters' IV and V 
will illustrate the DMS and Wal-Mart Stores, Inc. as the DoD 
and industry examples, respectively, of X.400/X.500 enterprise 
systems. Finally, Chapter VI will, after recapitulating 
industry lessons-learned on X.400 installations, provide 
possible solutions for DoD components who want to incorporate 
X.400 into their electronic messaging environment so that they 
may have the functionality of the standards in the interim 
period of the DMS X.400 implementation. 



9 



II. X.400/X.500 ENTERPRISE SYSTEM REQUIREMENTS 



A. DEFINITION OF X.400/X.500 

In October 1984, the Plenary Assembly of the CCITT 

accepted a standard to facilitate international message 

exchange between subscribers to computer based store-and- 

forward message services. This messaging transport standard 

is known as the CCITT X.400 series recommendations and happens 

to be the first CCITT recommendation for a network application 

(Houttuin. 1993, p.5). In October 1988, CCITT published a 

totally rewritten set of standards which increased the 

functionality of the 1984 standards. There were five 

significant improvements to the message handling architecture 

that included the Message Store (MS), distribution lists, 

X.500 directory services, support for postal delivery systems, 

and security. In addition, X.400 protocol layering 

architecture changed substantially to incorporate recent 

changes to the Open Systems Interconnection (OSI) upper layers 

and to provide a design that is more consistent with other OSI 

applications. (Burns, Radicati, 1992, p. 179) 

X.400 has been defined as follows: 

The primary role for X.400 has been to define 
a format for the electronic envelope, so that 
an X.400 backbone can transmit messages 
regardless of contents (Brennan, 1992, p.S22). 
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If the "electronic envelope" depicts the X.400 role, then 
the functional aspect of the CCITT X.400 family of standards 
can be described as a model for a Message Handling System 
(MHS) and associated services and protocols. In the context 
of the MHS, "users" may be either humans or application 
processes. The User Agent (UA) is a process that makes the 
services of the MHS available to the user. The services are 
grouped into message transfer services and interpersonal 
messaging services . These services are further divided into 
three categories: basic, essential optional, and additional 
optional. To illustrate these categories, Table 2-1 lists 
the services provided by the Message Transfer Agent (MTA) 
(Stallings 1991, p.745) 

The CCITT X.400 family of standards for Message Handling 
Systems is identified below: 

• X.400 This number represents the Systems and Service 
Overview and defines the message handling system model. 
It consists of Uas and MTAs , discusses naming and 
addressing, defines interpersonal messaging and message 
transfer services as well as protocols for implementation. 



• X.402 This number represents the Overall Architecture 
and serves as a technical introduction to it. 

• X.403 This number represents Conformance Testing 

specifying the criteria for acceptance of an 

implementation as conforming to the X.400 family of 
recommendations . 

• X. 407 This number represents Abstract Service 

Definition Conventions and defines techniques for formally 
specifying the distribution information processing tasks 
that arise in message handling. 
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TABLE 2-1: BASIC AND OPTIONAL SERVICES PROVIDED BY THE MTA 



Message T ransfer Agent 



Basic Services 

Acess Management Enables UA to submit and have msgs delivered to it 



Content type indication 


Specified by originating UA 


Converted indication 


Specifies any conversion being performed on msgs being delivered. 


Submit/Deliver Time Stamp 


Both times are supplied with each msg. 


Message Identification 


Unique identifier for each msg. 


Nondelivery notification 


Msgs cannot be delivered. 


Registered encoded info types 


Allows UA to specify types that can be delivered to iL 


Original encoded info types 


Specified by submitting UA and supplied to receiving UA. 



Essential Optional Services 



Alternate recipient allowed 


Deliver to alternate if designated recipient not found. 


Deferred delivery 


Deliver no sooner than specified date and time. 


Deferred delivery cancellation 


Abort delivery of deferred msg. 


Delivery notification 


Notify originator of successful delivery. 


Disclosure of other recipients 


Disclosure list of other recipients to recipient 


Grade of delivery selection 


Request urgent, normal or non urgent 


Multi-destination delivery 


Specify more than one recipient 


Conversion prohibition 


Prevents MTS from conversion 



Probe Determines if msg could be deliverable 

Additional Optional Services 

Prevent non-delivery notice Supress potential non-delivery notification 



Return of contents 


Return msg contents if non delivery 


Explicit conversion 


Specifies specific conversion 


Implicit conversion 


Perform all necessary conversions on all msgs without explicit instruction 


Alternate recipient assignment 


Request designation of requesting UA as alternate recipient 


Hold for delivery 


Requests that msgs intended for specific UA be held in the MTS until sue 
specific time 
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• X.408 This number represents Encoded Information Type 
Conversion Rules to allow dissimilar devices to exchange 
messages. The encoded information types that are handled 
include Telex, Teletex, ASCII terminals, facsimile, and 
videotex . 

• X.411 This number represents the Message Transfer Layer 
conceptually defining the message transfer layer service 
and the message transfer protocol. 

• X.413 This number represents the Message Store defining 
its services. 

• X.419 This number represents Protocol Specifications 
defining the protocols for accessing the MTS, the MS and 
those that are used between MTAs to provide for the 
distributed operation of the MTS. 

• X.420 This standard defines the services provided by 
interpersonal messaging and procedures for providing those 
services. (Stallings, 1992, p.738) 

Ratified in 1988, X.500 is the CCITT standard that will 
provide the Global Directory Services for X.400. X.500 

provides for naming facilities over networks, and it enhances 
the X.400 addressing mechanism by improving mail addressing 
within large, distributed message systems. Linked but 
dissimilar E-mail systems can now have common directories, a 
feature that hides complex addressing schemes from users . 
These directories are maintained on X.400 file servers. 
Directories can be accessed independently by any number of 
components, including Uas, MTAs, Access Units (AUs) and 
Message Store (MS) facilities, and even directly by end users. 
(Burns, Radicati 1992, pp. 180-182). These components are 
fully defined in the next section. 
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B. HOW AN X. 400 /X. 500 MESSAGE HANDLING SYSTEM WORKS 

In an X.400 system, users are provided with the capability 
of sending and receiving messages. The interface to the 
actual user (whether human or process) is accomplished through 
the User Agents (Uas) . For example, a UA may be implemented 
in the MHS as a computer program that provides utilities to 
create, send, receive and archive messages. Each UA is 
provided a "name" so that the Message Transfer System (MTS) 
can transfer messages from an identified originating UA to a 
specific receiving UA. Basically, Uas pass messages to Message 
Transfer Agents (MTAs) until the messages reach their 
destinations. As shown in Figure 2-1, which illustrates the 
components of a distributed messaging system, the actual work 
of message transfer is done in the MTS by the MTAs. Prior to 
forwarding the message to another MTA or a UA, the MTA 
validates the submission envelope and performs housekeeping 
functions such as recording submission time and generating a 
message identifier. Although not pictured in Figure 2-1, it 
is important to note that the MTA may store the message in a 
"mailbox" facility called a Message Store (MS) to be picked up 
later by a UA. Sometimes the MTA that accepts submission of 
a message delivers it directly to a UA or MS. Given the 
functionality of the MS, it could conceptually be located 
throughout the MHS and/or on the logical boundary between the 
MHS and the MTS. Other scenarios require MTAs to relay the 
message to one another until it reaches its destination. 
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OTHER TELEMATIC SERVICES 



USER 
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USER 



Figure 2-1: Components of a Distributed Messaging System 
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Using such a relay eliminates the need to have all UAs and 
MTAs available on a 24-hour basis; and, combined with the MS 
component, allows the office to "shut down" at night. The 
specific functionality of the MS can be defined as follows: 

• One MS acts on behalf of one user (ie., one originator/ 
response address) . 

• When a UA subscribes to a MS, all messages destined for 
the UA are delivered to the MS. When a message is 
delivered to a MS, the role of the MTS in the transfer 
process is complete. 

• The MS stores only delivered messages, not those being 
submitted . 

• An "alert" may be requested when a certain message 
arrives . 

• Message submission from the UA to its MTA, via the MS, is 
transparent . 

• Users are provided with basic message management 
facilities such as selective message retrieval, delete and 
list . 

In effect, the MS specification is simply a standardized 
definition of how otherwise local UA functions have been taken 
over by a separate system and accessed via a protocol. 
However, prior to the 1988 specification, messages sent from 
the UA to the MTA could be lost if the MTA was not ready to 
accept them. The lights had to be on. So, the MS was 
critical to expanding the functionality of X.400. (Stallings 
1991, p . 738-740 ) 

Finally, X.400 also facilitates communication between 
different E-mail systems by acting as a translator. An Access 
Unit (AU) provides a gateway between the MHS and the external 
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communication service such as TELEX. The rules for conversion 



of coded information are defined, making standardization of 
the conversion of message contents for transfer between 
dissimilar systems possible. Figure 2-2 depicts the process 
of message construction and transmission. Outside the scope 
of X.400, the user prepares the body of a message using, for 
instance, a word processor. The user presents the message 
body together with a description such as the subject, 
recipient and priority to the UA. The UA appends a header 
containing this qualifying information to the message. The 
MTA appends an envelope to the message containing the source 
and destination addresses and other control information needed 
for relaying the message throughout the network. (Stallings, 
1991, p.741) 

An example of the format for a standard X.400 message 
address for an E-mail network is 

c= { }/admd={ }/prmd={ }/o={ }/s={ }/g={ > 
where c=country; admd=administrative management domain; prmd= 
private management domain; o=organization ; s=surname; and 
g=given name (Burns, Radicati 1992, p.175). Using the above 
format, a typical address might be: 

c=US/admd=telmail/prmd=NPS/o=ms/s=msdosl 

As mentioned in the previous section, X.419 is the part of 
the X.400 standard providing protocol specifications. How do 
these protocols work? Basically, they are located in the 
application layer (layers 6 or 7 of the model depending on the 
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representation of the model) of the OSI model. It is assumed 
that the lower layer protocols used in the OSI network model 
are compatible between disparate systems. 

The X.419 protocols consist of (1) the Message Transfer 
Protocol (Pi) which acts as the "backbone switching" protocol 
that relays messages and other interactions among various 
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MTAs ; (2) the Remote UA Access Protocol (P3) which acts as a 

remote procedure call by enabling a UA that is remote from its 

MTA to obtain access to the MTS; and (3) the MS Access 

Protocol (P7) which provides a mailbox facility. The 

following is an example of the use of these protocols: 

User A sends a message to User B and User C. The message 
is handed over to User A's UA, which submits the message 
after putting it in an envelope. The envelope is, in 
effect, the header of a P3 protocol data unit. The MTAs 
take over the transfer of the message until it reaches an 
MTA which can make a delivery of the message. The routing 
of the message among the MTAs is accomplished with the PI 
protocol. The recipient. User B, gets delivery to B's UA, 
via protocol P3, where it can be directly read. For 
recipient, User C, a copy of the message is delivered into 
C's MS from where it can later be retrieved via protocol 
P7 . (Stallings 1992, pp. 743-744) 



C. ISSUES FOR AN X.400/X.500 ENTERPRISE-WIDE SYSTEM 

Since X.400 works independently with respect to any one 
operating system, it is ideal for global communications. 
However, there are a number of issues that need to be taken 
into account prior to implementing an X.400/X.500 enterprise- 
wide system. Most of these issues will be highlighted in the 
next chapter which provides methods for obtaining X.400 
functionality as well as some product information. 

First, there are few X.400 (1988) products because the 
majority of the vendors who invested research and development 
in X.400 did so with the 1984 standard. This leads to a 
related issue; since the 1984 specifications were not 
completely thought out, vendors have basically had to rewrite 
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their 1984 products. Many vendors still feel this is risky as 
well as costly, and have therefore been slow to do so. 
(Korzeniowski , 1993, p.NP4) 

Secondly, there is a lack of domestic interest and support 
in the OSI Model, on which X.400 is based. The TCP/IP Internet 
has made a "de facto" standard network model. The E-Mail on 
the TCP/IP Internet is supported by the Simple Mail Transport 
Protocol (SMTP) . SMTP gained widespread acceptance in three 
years compared to nearly a decade for its OSI counterpart, 
X.400. Nevertheless, industry, in general, has accepted X.400 
as the standard of the future since it has the potential to 
provide much more functionality than SMTP. Yet, many industry 
experts believe E-mail customers want to keep the TCP/IP 
infrastructure for their messaging transport mechanism. 
Figure 2-3 illustrates this dilemma with the ISO Development 
Environment (ISODE) link between X.400/X.500 and TCP/IP as a 
possible interim solution until the ideal network messaging 
model is achieved. 

As Chapter III will illustrate, corporations who have 
invested in X.400/X.500 have discovered it requires a fair 
amount of customization before deployment. So, the third 
issue is that if a company or agency desires to implement an 
X.400/X.500 messaging environment, it will most likely 
experience transition problems. Time and expert personnel 
must be scheduled to iron out implementation bugs. This 
phenomenon is primarily due to vendors interpreting and 
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"de jure" "de facto" 



Figure 2-3: ISODE and Integration Issues With X.400 and 

TCP/IP 

implementing the X.400 series recommendations differently in 
their products. Consequently, X.400 can be viewed as a 
standard that provides a common set of messaging features and 
not a full-blown integration tool. (Korzeniowski, 1993, p.NP6) 
Finally, with respect to directory services. E-mail 
vendors using the X.500 (1988) specification often add 

proprietary extensions to handle directory updates since the 
spec does not have this aspect automated. Thus, it still calls 
for manual updates. The 1992 X.500 specification improves 
directory synchronization, but products and services based on 
this specification may not be available for four or five more 
years. (Burns, Radicati, 1992, p.182) 
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These issues provide serious challenges for Information 
Systems managers as they administer or create architecturally 
efficient and effective messaging infrastructures. 
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III. 



X.400/X.500 IMPLEMENTATION ISSUES 



While both the Department of Defense services and agencies 
as well as companies flatten their organizational structures 
and pull together merged commands or business units, 
Information Systems (IS) managers are seriously challenged as 
they try to physically and logically connect all the different 
E-mail systems. As defined in the previous chapter, 
incorporating the CCITT X.400 series recommendations into the 
messaging infrastructure is one way to accomplish this. This 
chapter will introduce three methods of obtaining X.400 
services and discuss the integration of them with excerpts 
from a ZD Labs report. (Burns, Radicati, 1992, p.168) The 
report illustrates how well X.400 technology and products 
performed during a test of X.400 connectivity in a "typical" 
corporate computing environment. 

A . ALTERNATIVE METHODS 

Basically, there are three methods by which X.400 services 
can be obtained: (1) connect through a public E-mail service 
provider; (2) establish a corporate-wide X.400 mail handling 
system; or (3) install proprietary E-mail packages with X.400 
gateways and/or servers. 



23 



1 . 



Public X.400 E-Mail Service Providers 



Public E-mail providers are the fastest and simplest 
way to set up X.400 links. They offer a subscription similar 
to telephone service in that they provide installation, 
configuration, maintenance and support as part of the service. 
The subscriber usually pays a set-up charge and a "per 
message" charge based on usage, typically 30 to 95 cents per 
message. For businesses that are light on mail traffic, 
public E-mail providers are most cost effective since 
installation costs are low and the providers take on the 
burden of integration and management issues. They also 
provide enhanced services like accounting and monitoring. The 
disadvantage of using public E-mail providers includes 
escalating costs as E-mail volume rises, less control over the 
E-mail links, and, possible privacy and security risks. 
(Burns, Radicati, 1992, pp. 168-169) 

All the big carriers, AT&T, MCI and Sprint, have X.400 
gateways that they manage for their subscribers, although they 
typically do not use X.400 internally. Their Electronic 
Messaging packages are called AT&T Easylink, Sprint Mail and 
MCI Mail. (Lotus, 1993, p.4) 

2. Corporate-Wide X.400 Mail Handling System 

This option for X.400 connectivity requires purchase 
of the hardware and software needed to build in-house X.400 
services. The advantages of this strategy include complete 



24 



control over the E-mail system, its security and performance. 
Additionally, it offers better integration with existing 
corporate computing and data processing functions than public 
link services do. The primary disadvantage with installing a 
corporate-wide X.400 mail handling system is the burden it 
places on the MIS personnel with planning, design, 
configuration, product compatibility issues, and day-to-day 
maintenance and support . 

If a corporation decides to build its own X.400 
infrastructure, there are a number of minicomputer vendors 
such as DEC and HP that provide all the components needed for 
storing and routing X.400 messages. In most cases, these 
vendors have adopted X.400 capabilities on their own sites and 
are actively promoting an architecture that they use on a day- 
to-day basis. DEC is one of the few vendors that also offers 
an X.400 client or UA, which is the front end or user 
interface to the messaging system. Most vendors use 
proprietary UAs and E-mail servers that link to X.400 
gateways, as will be discussed next. (Burns, Radicati, 
1992, p.169) 

3. Proprietary E-Mail System With X.400 Gateway 

Most PC-based E-Mail vendors and minicomputer and 
mainframe computer messaging systems have X.400 gateways 
between their proprietary messaging systems and X.400 (Burns, 
Radicati, 1992, p.169). Vendors make their proprietary mail 
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servers "talk" to a gateway prior to accessing X.400 MTAs . 
Some X.400 gateways perform a conversion between the vendor's 
own proprietary mail protocol and X.400 protocols. On the 
other hand, a number of third-party vendors such as Retix, 
DEC, World Talk and Soft-Switch provide X.400 gateways and/or 
servers for connecting dissimilar messaging services from 
different E-Mail vendors. These products support not only a 
wide selection of proprietary protocols but also provide the 
message handling agents (UAs and MTAs) required for sending 
X.400 messages. Some of these products include directory 
services that tie together dissimilar E-mail directory 
formats. At the high end of the X.400 gateway market, Soft- 
Switch has the most comprehensive and technically advanced 
product; however, it requires a mainframe and is relatively 
expensive, at approximately $100,000 for hardware and software 
versus a PC-based solution such as Retix' s listed at 
approximately $5500. Retix has incorporated an effective 
strategy of developing a wide range of software options that 
allow most of the popular PC-LAN messaging systems, such as 
Microsoft Mail, cc:Mail, and Novel MHS , to access its 
OpenServer 400 MHS thus increasing the number of different 
MHSs a corporation can link with. (Burns, Radicati, 1992, 
p.172) Figure 3-1 illustrates a possible configuration for 
some of the X.400 gateways and/or servers. 

The decision of whether or not to use a single, multi- 
protocol gateway or a multiple-gateway solution depends 
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Figure 3-1: X.400 Connectivity of Proprietary E-Mail 

Packages 



largely on the composition of the installation. In general, 
it is best to minimize the number of gateways because their 
installation, configuration, maintenance and support 
requirements vary. Using a third party product that provides 
interoperability among all the installed environments and 
X.400 is the preferred way of reducing the number of gateways 
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needed for a company's messaging requirements. (Burns, 
Radicati, 1992, p.172) 

In light of the three methods of obtaining X.400 
services that were described in the preceding pages, 
implementation of X.400 in a particular business may require 
one, two or all three of those methods. A business must 
consider the number of users, the number of different mail 
systems that need to be connected, and, the level of in-house 
support available. 

B. EVALUATION OF INTEGRATED X.400 ENVIRONMENT: ZD LAB REPORT 

Corporate Computing, in its June/July 1992 issue, analyzed 

the conditions for implementing and managing an X.400 system 

in a corporate environment. Specifically, their scenario was 

a large business with different departments running 
isolated E-mail systems. The goal was to provide 
companywide communications by linking the various mail 
systems using X . 400-compliant products. (Burns, Radicati, 
1992, p.174) 

1 . Methodology 

To evaluate X.400 technology and products, Corporate 
Computing and ZD Labs designed and built an integrated, 
multivendor, multiplatform mail system. They used an X.400 
backbone and gateways from a variety of vendors linking PC- 
based LAN E-mail systems with Unix VAX and mainframe E-mail 
systems. They also connected to public E-mail providers and 
to third-party E-mail integration packages. They examined 
the pitfalls and advantages of X.400 from the perspective of 



28 



the corporate E-mail decision-maker. They wanted to know how 
much expertise was required to successfully install X.400 
products as well as compare the capabilities of X.400 
messaging with those of typical E-mail systems. Finally, they 
looked for differences in ease of use and manageability. The 
E-mail integration challenge is summed up in Figure 3-2. 
(Burns, Radicati, 1992, p.168) 
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The products tested by ZD labs were installed on the 
following platforms: DOS, Windows, Macintosh, Unix, VAX, and 
VM (IBM Systems/370) 1 . 

The E-mail packages included: Microsoft Mail version 
2.1 (DOS, Mac, OS/2 and Windows); Lotus' cc:Mail version 3.1 
(DOS, Mac, OS/2 and Windows); HP OpenMail V . A . 00 . 02 . 03 ; and 
DEC All-in-1 Mail for VMS version 4.1; and IBM PROFS Release 
2 . 21 . 

The Gateways were Microsoft Mail Gateway to X.400 
version 3.0, Retix cc:Mail X.400 gateway, DEC Message Router 
X.400 Gateway version 2.2, Hewlett-Packard HP X. 400/9000 
c.02.00, and Soft-Switch X.400 Gateway version 1 level 3. 2 



1 The DOS, Windows, and OS/2 workstations were, specifically, 
Gateway 2000 80386/33c PCs with 120MB hard drives and 8MB of 
memory. An Ethernet Novell NE 2000T network interface card was 
installed in each workstation. 

The Macintosh workstations were MAC HCis with 8MB of RAM, 
System 7.0.1, and a Technology Work Nu-Bus lOBase-T Ethernet 
adapter . 

The DEC VAX system was a VAXserver 3100 Model 48 with 24MB 
RAM and over 1.5 gigabytes of hard disk storage. Unix ran on an 
HP9000/825 with 32MB of memory and a 400MB hard disk. Finally, 
PROFS was accessed through a 327 0 terminal connected to an IBM 
System/370 located at Soft-Switch. (Burns, Radicati, 1992, p.172) 

The Microsoft X.400 gateway, Retix Open Server 400 and 
Retix X.400 cc:Mail gateways ran on the same Gateway 2000 
workstations. The Microsoft Mail gateway was connected to the 
Retix Server through an Eicon EiconCard HSI/PC X.25 interface card 
and a Black Box Modem Eliminator. The Retix server also included 
a Retix PC320 X.25 adapter with a PC321 daughter board. 

The HP X.400 gateway ran on the HP 9000/82 5 and the DEC 
Message Router X.400 was installed on the DEC VAXserver 3100/825. 
Soft-Switch's X.400 Gateway ran on a 25-MHz 80386 Data General with 
an Eicon X.25 card. (Burns, Radicati, 1992, p.172) 
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Connectionwise, the PCs were linked to a Cabletron 
lOBase-T Hub. The network file services were provided by 
Novell Netware 3.11 with Netware for Mac installed. The E- 
mail network was tied together with Retix's Open Server 400 ( 
SprintMail, and Soft-Switch X.400 Gateway. Figure 3-3 
illustrates the E-mail test start-up. (Burns, Radicati, 1992, 
p.172) 

Before starting the tests, the ZD Labs engineers and 
the participating vendors agreed upon the addressing and 
configuration parameters such as the 1984 implementation of 
the X.400 standard and its originator/recipient addressing 
model. To test the installation and configuration of the 
X.400 E-mail system, they accomplished the following: First, 
the ZD Labs engineers and the appropriate vendor technicians 
set up and tested each E-mail package as an isolated system 
until it was up and running. Second, they set up and tested 
the X.400 gateways until they were up and running. Third, the 
engineers established links by installing MTA software, 
reliable transport services (RTS), transport stacks (X.25 and 
LAN), routing tables and link information. Each system had 
unique X.400 setup procedures and components. Finally, they 
evaluated full E-mail integration by verifying that messages 
could be sent and received between all systems simultaneously. 

Two illustrations of the required connectivity for 
successfully passing a message between two different E-mail 
systems are illustrated in Figure 3-4. (Burns, Radicati, 
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Figure 3-3: ZD Labs E-mail Test Setup 
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Figure 3-4: Messaging From One E-Mail System to Another 



Requires Several X.400 Gateways and MTAs . 

1992, p.175) Messages addressed to users on the same E-mail 
system did not pass through X.400 gateways. Generally, 
messages addressed to users on other mail systems were routed 
through the Retix mail server which primarily acted as a 
central hub that supported the X.400 backbone. 

2 . Evaluation 

Within two days, Microsoft Mail, Retix Open-Server, 
Hewlett-Packard Open Mail, Lotus cc:Mail, and SprintMail were 
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exchanging simple messages over Ethernet and X.25 links. The 
only E-mail system they were unsuccessful in linking to other 
packages was DEC'S All-In-1. Messages were passed through all 
X.400 gateways with the exception of DEC'S VAX-based Message 
Router X.400. 

As with all MHSs, X.400 addressing must be exact. 
However, X.400 addressing is more complex, with more 
components than the addressing protocols associated with most 
E-Mail systems. Usually, the system administrator handles 
this aspect by typing the correct name and address into the 
"local" address book. Problems may arise when a user attempts 
to address a remote recipient by himself. 

In general, headers and even the text format (mostly 
line-spacing and tabs) changed as messages transferred from 
one MHS to another. Additionally, the gateways in the 
prototype network handled small file attachments, but were 
unable to handle large (two or three megabyte) files. 
Finally, most error messages and non-delivery notices were 
sporadic or not helpful in identifying the problem. (Burns, 
Radicati, 1992, pp. 176-178) 

3. X.400 Lessons Learned by Corporate Computing 

Overall, interoperability among the MHSs was good and 
the X.400 implementations were reliable. The transport or 
implementation of specific features by the UAs was where most 
of the problems were experienced rather than problems directly 
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related to the X.400 standard. Installation and debugging 
were challenging for both ZD Lab technicians and vendors. 
However, despite what they experienced, they believe that, in 
general, once a MHS is stable and its behavior understood, 
changes will be far easier to make and daily operations 
smoother . 

Assembling this complex, wide-area network did 
require a working knowledge of network architecture, transport 
protocols, packet-switched networks and X.400 specifications. 
Although installation time was enhanced with the very best 
available technical resources (the X.400 vendors themselves), 
it took more time than anticipated to configure each MHS ' s 
options. Broad knowledge about client-server operating 
systems and mail applications was also essential during 
installation. (Burns, Radicati, 1992, p.178) 

Nina Burns and Sara Radicati also give the following 
guidelines that may improve a business's X.400 implementation: 

• Contract with vendors or reliable third party service 
providers to help with initial design, planning, 
installation and configuration, especially if you don't 
have specific expertise in house. This will pay for itself 
many times over. 

• Train support people so you build expertise in-house and 
can maintain your systems in the long run. 

• Try to minimize the number of vendors involved in the 
construction of your system. For example, it may be a 
better approach to purchase all gateways from one vendor 
rather than individual gateways from each vendor. Many 
companies are consolidating their E-Mail systems so they 
only need to support three or four rather than eight or 
ten . 
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• If you purchase equipment from more than one vendor, bring 
them all together at the same time during installation. 
In addition, make sure you ask about interoperability 
testing to ensure that the equipment you are buying 
interoperates. Ask specifically about version numbers and 
system configuration, not just the X.400 system. 

• Watch out for updates and upgrades . Test everything 
before you install. You need to test compatibility all 
over again if one component changes. 

• Backbone designs are usually more efficient to manage than 
point-to-point gateways, as they have fewer interdependent 
components and less equipment, reducing maintenance 
requirements . 

• Evaluate the administrative interface and functionality of 
the systems. it's a woefully underappreciated fact that 
an easy-to-use interface can save valuable time and make 
troubleshooting easier by orders of magnitude. 



C. E-MAIL PRODUCT REVIEW 

This section provides a snapshot of today's top-three E- 
Mail products and the X.400 services they provide. The Local 
Area Network (LAN) E-Mail market is overwhelmingly dominated 
by Lotus Development Corp.'s cc:Mail, Microsoft Corp.'s 
Microsoft Mail and WordPerfect Corp.'s WordPerfect Office, in 
that order. In 1993, the LAN E-Mail market was estimated at 
$224 million in worldwide revenues according to International 
Data Corp., a market researcher in Framingham, Mass.. The 
trend is likely to continue as companies downsize to LAN-based 
packages from mainframe-based solutions and software suites 
become more entrenched. 

"The market used to be very fragmented, with the leading 
vendors taking 90 percent of the market," said Matt Cain, 
program director of the workgroup computing for Meta 
Group, a consultancy in Westport, Conn.. He continued, 
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"Lotus and Microsoft by the end of 1993 will have half of 

the worldwide installed base of E-Mail users, and those 

two companies account for 60 percent of all new sales." 

(Rooney, 1993, p.116) 

According to Dave Whitten, program director of office 
information systems for Gartner Group Inc., a market 
researcher in Stamford, Conn., WordPerfect had only 11.6 
percent of the LAN E-Mail market at the end of 1992. In 
September of 1993, it had 14.6 percent. (Rooney, 1993, p.116) 
The main features of these packages as well as X.400 
services provided are listed below: 

Lotus Development Corp.'s cc:Mail 

• General Description : cc:Mail is a "family" of more than 20 
LAN-based products that provide high-end, multimedia E- 
Mail capabilities to users of all operating systems listed 
below. It provides connectivity with LAN, mini- and 
mainframe-based E-Mail systems and can connect to public 
E-Mail services and fax machines worldwide. 

• Operating Systems cc:Mail Products Support: DOS: cc:Mail 

for MS-DOS 4.01 runs under all versions of DR, PC or MS- 
Dos 3.1 or later; OS/2: cc:Mail for OS/2 3.2 runs under 
OS/2 l.X and 2.0 cc:Mail for DOS and Windows can run under 
OS/2 2.0; Windows: cc:Mail for Windows 1.11 supports 

Windows 3.0 and 3.1; Macintosh: cc:Mail for Macintosh 2.0 
runs on System 6. Ox, System 7, and A/UX 2.0; Unix: cc:Mail 
for Unix 1.0 runs on Sun SPARC stations with the OPENLOOK 
user interface. (Lotus, 1993, p.5) 

• Gateway Connectivity : Gateway products (meaning that you 
have to buy them in addition to cc:Mail package) from 
cc:Mail and leading third party vendors to allow 
connectivity with major E-Mail systems in the world. 
Cc:Mail offers gateways to Novell MHS, IBM PROFS, 
SMTP/ UNIX /uucp , 3COM, MCI, AT&T, Sprint. In order to 
obtain X.400 connectivity . you must obtain other vendors' 
gateway support (such as Retix or Soft-Switch). (Lotus, 
1994, p . 7 ) 

• Standards Support: cc -.Mail's standards support includes 
the following data communications standards: Novell's MHS, 
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X.400, SMTP and X.25 via the Lotus Communications Server 
and/or cc:Mail gateway products. (Lotus, 1994, p.4) 



Microsoft Corp.'s Microsoft Mail 

• General Description: Microsoft Corp . provides a multi- 
media capable (Basically, this translates to sound and 
graphics files being incorporated into the mail file) LAN- 
based E-Mail product. It provides connectivity with LAN, 
mini- and mainframe-based E-Mail systems and can connect 
to public E-Mail services and fax machines worldwide. It 
supports users on the following operating systems: 

• Operating Systems Microsoft Mail Products Support: DOS: 

Microsoft Mail for MS-DOS runs under all versions of MS- 
Dos 3 . 1 or later; OS/2: Microsoft Mail for OS/2 runs under 
OS/2 1.2 or later; Windows: Microsoft Mail for Windows 
supports Windows 3.0a or later; Macintosh: Microsoft Mail 
for Macintosh runs on System 6.0.3 or later; Unix: 
Microsoft Mail does directly support unix at this time. 
(Microsoft, 1994, p.4) 

• Gateway Connectivity : Gateway products from Microsoft 

(meaning that you have to buy them in addition to the 
Microsoft Mail package) for connectivity with major E-Mail 
systems around the world include: Microsoft Mail Gateways 
to IBM, PROFS and Office Version, X.400, Fax, SMTP, MHS, 
MCI Mail, 3Com 3+Mail, and Microsoft Message Service for 
IBM SNADS . (Microsoft, 1994, p.8) 

• Standards Support: Microsoft boasts that it's Mail and 
gateway package is the only single, complete solution 
available today for high-quality connectivity between a 
LAN-based mail solution and international standard X.400 
systems. This is no longer true since WordPerfect 
Corporation launched its own X.400 gateway product in 
January 1994. Additional data communications standards 
support include: Novell's MHS, SMTP and X.25 via the 
Microsoft Mail Server and/or Microsoft Mail gateway 
products. (Microsoft, 1994, pp . 8 and 9) 



WordPerfect Corp.'s WordPerfect Office 4.0 

• General Description: WordPerfect Office 4.0 is an office 
automation product which includes E-Mail as part of its 
functionality. Specifically, the product supports group 
calendaring and scheduling, task management (who told whom 
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to do what), workflow management (ordered distribution), 
message and outbox management (status of messages sent), 
system administration and gateway support management. 
(WordPerfect, 1994, pp . 1-2) 

• Operating Systems WordPerfect Office Products Support: 
WordPerfect Office 4.0 supports PC users in the DOS 3 . 0 or 
higher environment, the Windows 3 . 1 or DOS for Windows 3.1 
or higher, and Macintosh System 7 or higher. 
(WordPerfect, 1994, p.3) 

• Gateway Connectivity : The following WordPerfect gateways 

are available separately from the WordPerfect Office 4.0 
product: PROFS and Office Vision/VM, SNADS, cc:Mail, 

Novell MHS , SMTP, X.400, MCI Mail and AT&T EasyLink. With 
respect to X.400, the WP X.400 gateway allows the X.400 
system to function as a long distance message transport 
service to connect with other external WP Office system 
users. The gateway operates on an OS/2 version 2.0 or 
higher environment. (WordPerfect, 1994, pp . 2,7-8) 



D. E-MAIL IN DOD 

As part of the Administration's "reinventing government 
initiative" led by Vice President A1 Gore, E-Mail is playing 
an increasingly important role in the Federal Government. In 
August of 1993, an interagency task force was created to 
design a strategy for providing interconnectivity among 
agencies. Its charter is to develop an infrastructure for E- 
Mail using X.400/X.500 standards. (Smith, 1993, p.68) 

The next chapter discusses the Department of Defense's 
role in this requirement with the Defense Message System (DMS) 
Program. One of the preliminary requirements was to 
identify the major products and quantities 3 in use by DoD 



3 These numbers are based on a DoD-wide survey conducted in 
1992 by DISA. As of March 1994, the current quantities in use of 
these E-Mail packages have not been identified. (Dittmer, 1994) 
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users that are desired for upgrade to DMS compliance. This 
enabled specifications to be written for X.400/X.500 
compatibility and connectivity. These packages are identified 
in Table 3-1. Not surprisingly, the worldwide E-Mail leaders 
are included. (DoAF DMS RFP, 1993, p.A13-l) 



TABLE 3-1: E-MAIL PACKAGES USED IN DOD AS OF JULY, 1992 



E-mail Product/# Components 



E-mail Vendor 

Lotus Development Corp . 
Microsoft Corp. 

Beyond Inc. 

Banyan Systems Inc. 

Da Vinci Systems Corp. 
Word Perfect Corp. 

LJL Enterprises, Inc. 



cc :Mail/85 , 730 
Microsoft Mail/62,000 
Beyond Mai 1/28, 000 
Banyan Mail/27,750 
Da Vinci eMail/16,000 
WordPerfect Office /6,000 
PC MAX E-mail/100,000 



Can these disparate E-Mail packages be incorporated in 
DMS? If ZD Labs test results are any indication, the answer 
will be "yes" with some compromises. Chapter IV has excerpts 
from DoD's draft Request for Proposal (RFP) for the DMS that 
was released to industry for comments September 1993. 
Overall, the chapter illustrates the basic plan for an 
X.400/X.500 enterprise, or DoD-wide messaging infrastructure 
with specific focus on the E-Mail requirements. 



40 



IV. 



X.400/X.500 AND THE DEFENSE MESSAGE SYSTEM 



A. BACKGROUND OF DMS 

In January, 1988, the Assistant Secretary of Defense 
(ASD) / Command, Control, Communications and Intelligence (C3I) 
formed a multi-Service and agency Defense Message System 
Working Group (DMSWG) to assess the future of DoD's messaging 
system. The primary objectives were to: first, define the 
baseline DMS; second, reliably estimate its cost to the DoD; 
and third, formulate a target DMS architecture based on 
achievable technology. The DMSWG developed a Target 
Architecture and Implementation Strategy (TAIS) by using 
inputs from Government and industry, and by capitalizing on 
advances in technology and standards. The conceptual TAIS was 
approved by the Defense Acquisition Board in May 1988; and the 
Under Secretary of Defense for Acquisition issued DMS Program 
Guidance in August 1988. The Program Guidance provided 
approval of the target architecture, the phased implementation 
strategy, the test and evaluation and the management 
structure. Additionally, it tasked the Defense Communication 
Agency (now called the Defense Information Services Agency 
[DISA] ) with responsibility of overall DMS coordination, and 
provided initial tasking to the services and agencies 
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necessary to begin execution of the DMS implementation 
strategy . 

In October 1988, the DMS management structure was fully 
activated. By February 1989, the Joint Staff implemented the 
validated Multi-command Required Operational Capability for 
the DMS (MROC-DMS) . Finally, in accordance with the interim 
policy guidance, transition planning is now underway by all 
services and agencies. (TAIS, 1993, p.1-1) 

As mentioned, one of the first tasks for the DMSWG was to 
identify a DMS "baseline" to serve as the reference against 
which the future cost , manpower and performance during the 
evolution to the target architecture would be measured. It is 
important to note that this baseline is "frozen" in time, and 
will not change over the DMS planning period. 

B. DMS BASELINE COMPONENTS 

The primary components of the DMS baseline are the 
Automatic Digital Network (AUTODIN) system which provides 
organizational messaging between organizational elements 
(usually chain of command) and electronic mail on the DoD 
Internet (called the Defense Data Network or DDN) providing 
messaging capability between individuals (staff personnel). 

The components of the AUTODIN are: (TAIS, 1993, pp . 2-1, 2-3) 

• AUTODIN Switching Centers (ASCs) - The ASCs, of which 
there are 15 operational ones throughout the world, 
perform store-and-f orward message switching functions, 
some message validation functions, format conversion and 
some specialized routing functions. 
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• Automated Message Processing Exchanges (AMPEs) - There are 
over 100 AMPEs worldwide which include the Navy's Local 
Digital Message Exchange (LDMX) , the Army's Automated 
Multi-Media Exchange (AMME), the Air Force's Automated 
Message Processing Exchange (AFAMPE) , National Security 
Agency's STREAMLINER and Defense Intelligence Agency's 
Communication Support Processor (CSP) . The AMPEs provide 
concentrator and limited switching for attached terminals, 
plus other functions such as conversion of destination 
names (Plain Language Addresses [PLAs]) into internal 
AUTODIN addresses (called Routing Indicators [RIs] ) . 

• Telecommunication Centers (TCCs) - TCCs are the principal 
entry and exit points for AUTODIN messages. TCCs contain 
administrative message centers with manual 
over-the-counter operations, a variety of terminal 
equipment, optical character readers and video display 
terminals to enter messages. 

• Data Processing Installations (DPIs) - The message 
function of sending and receiving data rather than 
narrative messages is accomplished by the interfaces 
between AUTODIN and the DPIs. This interface can either 
be direct into an ASC or indirect via an AMPE . 

• Automated Message Handling Systems (AMHSs) - Some users of 
the DMS baseline have implemented AMHSs which assist in 
the automated processing of messages. This may include 
message coordination and release, storing, sorting and 
retrieving messages, and electronic mailbox distribution 
schemes . 

« Directories (DIR) - DIRs are paper documents such as the 
Message Address Directory (MAD) containing organization 
names and associated PLAs and the ACP 117 series of 
publications which include PLAs with assigned Ris for 
AUTODIN recognition. 

The baseline architecture is represented in Figure 4-1. 

(TAIS , 1993, p.2-2) 



C . DMS REQUIREMENTS 

The main problem with the DMS baseline is one of 
interoperability. While both primary components provide 
messaging service to DoD users, their disjointedness prevents 
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Figure 4-1: DMS Baseline Architecture 
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the interoperability required to allow an efficient and 
effective exchange of message traffic from AUTODIN to DDN. In 
order to solve this problem, the following brief requirements 
have been identified for DMS : (TAIS, 1993, pp.1-4 to 1-6) 

• Connectivity/Interoperability - Within the community of 
users identified as organizations and personnel in the 
DoD, the DMS should allow a user to communicate with any 
other user whether fixed or mobile. Additionally, DMS 
must support interfaces to systems of other government 
agencies, allies, tactical and defense contractors . 
Connectivity must extend from writer to reader. And, it 
should lead DoD's migration to international standards and 
protocols . 

• Guaranteed Delivery and Accountability - With a high 
degree of certainty, DMS must deliver a message to the 
intended recipient ( s ) . Prompt notification of non- 
delivery to the sender must occur if the system cannot 
deliver a message. 

• Timely delivery - The DMS must recognize messages that 
require preferential handling. It must also dynamically 
adjust to changing traffic loads and conditions during 
peacetime, conflict and war. Delivery time will be a 
function of message precedence and system stress level. 

• Confidentiality/Security - The DMS must process and 
protect all levels and compartments of classification of 
message traffic. It must maintain separation of messages 
within user communities to ensure confidentiality or the 
preclusion of access to or release of information to 
unauthorized recipients. Security will also be based on 
requirement for authentication and integrity as well as 
confidentiality . 

• Sender Authentication - Information marked as having 
originated at a given source must be unambiguously 
verified by the DMS. For organizational traffic, a 
message must be approved by competent authority before 
transmission . 

• Integrity - Information content received must be the same 
as that sent. If authorized by the writer, DMS may make 
necessary format changes to account for differences 
between the component systems serving the writer and the 
reader . 
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• Survivability - The DMS must not degrade the survivability 
of the systems interfaced to it . Methods such as 
redundancy, proliferation of system assets and distributed 
processing may be employed to achieve survivability. 

• Availability/Reliability - The DMS must provide message 
service to users on a continuous basis. Availability will 
be achieved through a combination of reliable and 
maintainable components, thoroughly tested software, and 
necessary operational procedures. 

• Ease of Use - Use of the DMS should not require extensive 
training or the knowledge of a communications specialist. 

• Identification of Recipients - The sender must be able to 
unambiguously identify to the DMS the intended 
recipient ( s ) . The necessary directories and their 
authenticity are part of the DMS. 

• Message Preparation Support - User-friendly preparation of 
messages for transmission must be provided by the DMS 
(i.e., U.S. Message Text Format assistance) 

• Storage and Retrieval Support - The DMS must promote 
storage of messages after delivery to allow retrieval for 
such purposes as readdressal, retransmission and automated 
handling functions with the capability of incorporating 
segments into future messages . 

• Distribution, Determination and Delivery - For 
organizational message traffic, the DMS must determine the 
destination (s) of each message (in addition to the 
addresses (s) specified by the originator) and ensure 
delivery in accordance with requirements of the recipient 
organization. For individual message traffic, delivery of 
each message to the individual (s) specified by the 
originator must be accomplished. 



D. DMS TARGET ARCHITECTURE & IMPLEMENTATION STRATEGY 

Summarized in Figure 4-2, the Target Architecture is shown 
in terms of the primary functional elements required to 
provide the DMS messaging services (TAIS, 1993, p.3-3). The 
message transfer agents (MTAs) , message stores (MSs) , user 
agents (Uas) , and organizational user agents (OAUs) accomplish 
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Figure 4-2: DMS Target Architecture 



47 



the X.400 message handling functions that were described in 
Chapter II. A hierarchical distribution directory (DIR) along 
with directory user agents (DUAs) provide the DMS X.500 
directory services. Security services are provided using the 
Secure Data Network System Message Security Protocol (SDNS 
MSP) and other various lower layer protection mechanisms. An 
MSP gateway provides the necessary interfaces with non-MSP DMS 
users in the NATO, allied, tactical, civil, commercial and 
research communities. These various functions are performed 
within physical components which are distributed 
geographically and organizationally, but act in harmony to 
provide the DMS services. (TAIS, 1993, p.3-2) 

The implementation strategy involves three phases spanning 
the years 1989 to 2008. Figure 4-3 illustrates this timeline 
and the corresponding objectives of each phase (TAIS, 1993, 
p.4-2) . 

1 . Phase 1 

The first phase emphasizes automation of existing TCC 
functions and extension of messaging services to users. 
Basically, there will be improvements in AUTODIN's directory, 
an AUTODIN- to-DDN interface capability, and a migration of DDN 
E-mail from SMTP to X.400. services and agencies will have the 
opportunity to phase out their resource-intensive baselevel 
TCCs, migrate AUTODIN data'pattern message traffic to the DDN, 
begin the organizational transition and prepare their 
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organizational and individual messaging communities for 
evolution to the next phase. (TAIS, 1993, p.4-1) 

2 . Phase 2 

The second phase will produce the most obvious 
architectural changes and improvements. It begins with the 
initial operational capability for X.400/X.500 individual and 
organizational messaging with SDNS MSP protection. The 
baseline procedures , protocols , formats, policies and 

standards will begin the migration to the target architecture. 
TCC functions and responsibilities will be shifted to OAU 
workstation applications, thus accelerating TCC phase-outs. 
With the simultaneous deployment of X.400 MTAs , X.500 

directory services, DMS management control capabilities and 
SDNS security protection, an integrated X.400/X.500 SDNS DMS 
organizational and individual messaging system will be rooted 
and maturing. AMPEs and ASCs will be phased out. (TAIS, 
1993, p.4-3) 

3 . Phase 3 

The third phase commences when the last ASC is closed. 
The primary emphasis during this phases is the maturation of 
the X. 400/X. 500/SDNS organizational and individual messaging 
system and achievement of the target architecture. The local 
and long haul portions of the DoD Internet will also mature 
and the DCS backbone will have evolved to a fully integrated 
Defense Information System Network (DISN) . (TAIS, 1993, p.4-3) 
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E. X . 400 /X .500 AND THE DMS 

1. Baseline E-mail on the DoD Internet 

In 1982, the Defense Data Network (DDN) was 
established. It is a set of world-wide networks that are 
based on technology developed by the Defense Advanced Research 
Projects Agency (DARPA) as the ARPANET in the early 1970's. 
One of the primary uses of the ARPANET was to provide E-mail 
to the DoD research community. This capacity was extended to 
other operational users on the DDN. The protocols that were 
in use in the early eighties were expanded for connection of 
baseline transmission facilities to wide-area networks. 
Collectively, the baselevel and long-haul transmission 
facilities are termed the DoD Internet; and, the expanded 
message transfer protocols for the Internet are Transfer 
Control Protocol (TCP) /Internet Protocol (IP) and the Simple 
Mail Transfer Protocol (SMTP) . The principal components of 
the E-mail system are host computers supporting E-mail, user 
terminals, on-line directories, and the DoD Internet. (TAIS, 
1993, p.2-8) Specifically, 

• E-mail hosts are computers that have (1) installed an 
application program which interfaces with users on 
terminals to compose, send and receive messages; and (2) 
implemented the Simple Mail Transfer Protocol (SMTP) as 
well as the necessary underlying protocols which allow 
them to send and receive mail from other E-mail hosts 
(which may include proprietary E-mail protocols) . 
Additionally, storage is provided by the host computers to 
keep received mail until the users have read it. 

• User terminals can be defined as any computer terminal or 
PC with terminal emulation software. 
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• Directories are exceptionally important since they are the 
phone books of E-mail. The DDN Network Information Center 
(NIC) computer contains a directory of over 50,000 E-mail 
users. It contains the user's name and mailbox address 
consisting of an identifier for the user and one for the 
E-mail host. A second directory containing host names and 
corresponding Internet addresses is also located at the 
NIC and is currently being distributed throughout the DoD 
Internet . 

• The DoD Internet is included for completeness since it is 
the avenue for E-mail . The DoD baseline Internet has three 
components. The first component is the classified DDN 
which is a set of physically, procedurally , and 
cryptographically secured packet switched segments. These 
segments are referred to as DSNETl, DSNET2 and DSNET3 . 
The second component is the unclassified DDN which is the 
packet switched segment providing the backbone for 
unclassified E-mail. The third component is the Baselevel 
Transmission Facilities which have traditionally supported 
switched voice circuits, dedicated point-to-point 
communications and simple star networks. MILNET is 
usually considered part of the DDN. 

( TAIS , 1993, pp.2-8 to 2-9) 

2. Transition to X.400/X. 500-based DMS 

For DoD services and agencies, individual messages are 
carried over the DDN using the Internet's Simple Mail Transfer 
Protocol (SMTP) . AUTODIN is used to exchange organizational 
(both classified and unclassified) messages in DoD. As Figure 
4-4 illustrates, DMS will convert the SMTP individual message 
transfer world into an X.400/X.500 combined (individual and 
organizational) message transfer world. The DMS Program is 
relying on another Program called the Defense Information 
System Network (DISN) , which is being managed concurrently 
with DMS, to transition (1) packet switching and sub-DSl 
transmission for today's DDN to broadband switching and 
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transmission; and (2) TCP/IP (Internet) network layers into 
the OSI Transport network layers. (TAIS, 1993, p.A-2) 

A high-level picture of what DMS is trying to accomplish 
with respect to X.400/X.500 and a message handling system is 
illustrated in Figure 4-4. 




Figure 4-4: DMS is Responsible for the Transition of a 

"SMTP MHS" to an "X.400 MHS" 
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3. X. 400 DMS Gateways 

Figure 4-5 depicts a transitional architecture for 
Phase I of the DMS (TAIS, 1993, p.A-46) . The primary 

importance of this illustration is gateway functionality. The 
architecture calls for gateway connections between (1) SMTP 
and X.400 users, (2) DISN and the global Internet and (3) 
AUTODIN and the MILNET segment of DISN. By Phase II, the 
gateways will provide the following AUTODIN-to-DISN Interface 
(ADI) and connectivity support: [TAIS, p. A-45] 

• AUTODIN- to -DISN Message Conversion. This conversion 
occurs when narrative messages are written by AUTODIN 
writers and routed to DDN E-mail readers by means of 
AUTODIN Plain Language Addresses (PLAs) . They are routed 
to the ADI and converted to DDN E-Mail addresses (i.e., 
SMTP and/or X.400) 

• DDN- to -AUTODIN Message Conversion. Basically, an E-mail 
user may generate an E-mail message and transmit it via 
SMTP or X.400 to the ADI, with AUTODIN PLAs included as 
part of the address. 

It is important to note that DMS specifications call 
for connectivity for both the Internet and OSI until DISN 
migration is complete. Therefore, gateways between SMTP and 
X.400 will be commonplace. Other gateways that will be 
required for E-Mail connectivity include: [TAIS A-48-56] 

• Mail Relay Gateway between DISN and the Global Internet is 
required to relay SMTP and X.400 mail. 

• Multi-Function Gateway between DISN and the Global 
Internet will translate between SMTP and X.400 
"classified-capable" users. It must be able to translate 
cryptographic mechanisms for DoD and its Allies. 



54 




Figure 4-5: DMS Gateway Transitional Architecture 
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• DMS-to-Tactical Gateways are required to include an X.400 
interface with the tactical and/or mobile users in order 
to bring them into the DMS E-Mail community. 4 

• Guard Gateway is required to ensure that classified data 
on DISNET is not passed inadvertently or intentionally to 
users on the MILNET. At the same time, it must allow 
unclassif ied-but-sensitive traffic to pass between the 
networks . 

• GateGuard is a generic, Navy-developed gateway to the 
commercially available Automated Information Systems 
(AISs) or the Office Automation Systems (OASs) with 
proprietary and SMTP E-Mail. It is used for the electronic 
delivery of AUTODIN messages from the user's desktop 
terminal . 

The above Phase 1 gateways are transitional devices 
needed at the application layers (layers 6&7 of the 7-layer 
OSI network model) to support the DMS message environment. 
Table 4-1 depicts the DMS transitional gateway requirements 
for a DMS user that is capable of sending and receiving 
AUTODIN, DDN E-Mail (SMTP), or X.400 messages. This user may 
or may not have the Preliminary Message Security Protocols 
(PMSPs) requirement for transmitting classified messages. It 
is important to note that the Message Security Protocol (MSP) 
conversion capability will be incorporated with the 
availability of MSP at the start of Phase II. Phase II and 



4 The tactical gateways include: (1) the Tactical Packet- 
Switched Network-AUTODIN Gateway which will bridge the Army's 
Tactical Packet-switched Network (TPN) with AUTODIN; (2) the 
Tactical Packet-switched Network-Defense Data Network Gateway which 
the Army requires to bridge its TPN with the classified network 
portion of the DDN; (3) the Naval Communications Processing and 
Routing System II Gateway which the Navy requires for a tactical 
gateway link to AUTODIN allowing interoperation with the X.400 
messaging environment; and, (4) the Navy X.400 Fleet Gateway used 
specifically for its interface with X.400 shipboard 
implementations. [TAIS, pp.A-50-51] 
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Ill gateway implementations and concept of operations have not 
been published at this time. [TAIS, pp. 86-88] 

Although not as large-scale as the DoD's DMS, the next 
chapter discusses the n tive X.400/X.500 implementation for 
000 users at Wal-Mart Stores Inc. that is currently 
srway . 
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V. WAL-MART STORES INC. ENTERPRISE MESSAGING SYSTEM 



A. BASIC HISTORY 

Wal-Mart Stores, Inc. is a large retailing business 
currently dispersed across approximately 2,000 locations, both 
foreign and domestic. Each employee of Wal-Mart, whether in 
a store, the corporate complex, one of Sam's Clubs, or a 
distribution center, is referred to as an "associate" of which 
there are currently more than 350,000. Wal-Mart has achieved 
its current success because of a history of "never being 
satisfied with the way things are. The company is a visionary 
one which "learns from and cherishes its past, but does not 
live in it." The following momentous highlights of one of the 
greatest retail companies in U.S. history illustrate their 
success: (Wal-Mart, 1993) 

• 1950 Sam Walton founded Walton's 5&10 in Bentonville, 
Arkansas. Rob Walton, the current Chairman of Wal-Mart 
Stores Inc. reflects on his father's early business, "When 
my brothers and sisters were growing up, we always worked 
in dad's stores ... sweeping floors, carrying boxes, even 
running the ice cream machine. I remember feeling that 
all the associates in the store were part of the family, 
always willing to help each other..." 

• 1963 First Wal-Mart store in Rogers, Arkansas solidified 
the concept that large discount operations can succeed in 
small towns. 

• 1970 Wal-Mart becomes a public company, entering the 
world of Wall Street. The 32 Wal-Mart stores had $31 
million in sales. 

• 1972 The Wal-Mart profit sharing plan was instituted. 
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• 1980 Over 300 Wal-Mart operated facilities brought in 
sales of $1.2 billion. Sam's Clubs and Supercenters 
became permanent divisions of the company. 

• 1992 Mr Sam Walton received the Presidential Medal of 
Freedom shortly before his death. 

• 1993 Wal-Mart is the largest retailer in the world, 

operating 1957 general merchandise discount stores, 163 
Sam's wholesale clubs and 68 Supercenter stores which 
combine food and general merchandise under one roof. Wal- 
Mart ' s revenue reached $67.3 billion in 1993 (Merrill, 
1994, p . 3 ) . The company is poised to explode into the 
international market and transplant the Wal-Mart way of 
doing business: customer service, great values and respect 
for each other, to other countries (Wal-Mart, 1993) . 

This preparation for the international market requires 

effective communications between the associates, the vendor 

partners, and the purchasing agents. The CCITT X.400/X.500 

family of message transfer standards will support Wal-Mart in 

achieving this worldwide messaging enterprise system. 



B. BACKGROUND OF WAL-MART MESSAGING SYSTEM 

Wal-Mart 's communications services in the past have 
included basic telephone services, U.S. and Wal-Mart postal 
services, and session-oriented computer connections. 
Electronic messaging systems are currently provided through 
the PROFS system and the Wal-Mart store message system. These 
systems have limited capabilities such that the company has 
basically outgrown them. The desired E-Mail system is defined 
as a " store-and-forward transport for electronic objects to 
include text, documents, forms, spread sheets, graphics, 
images and even digitized voice." The transport of these 
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objects can occur across heterogenous computers, LANs, and WAN 
protocol environments. 



C. E-MAIL REQUIREMENTS OF WAL-MART 

1. Identification of Wal-Mart' s MHS Platform And UAs 

Wal-Mart currently has an Ethernet-based X.400 E-Mail 
backbone which overlays on the internal computer networks with 
gateways to the public data networks. There are approximately 
1,000 users with X.400 E-Mail capabilities and 3,000 or so 
users of IBM's mainframe host environment, PROFS, which has 
provided most of the electronic messaging functionality for 
the company. Wal-Mart has identified the following UAs: 

• Direct-Connect Synchronous Terminal . The hardware platform 
for this UA is a synchronous terminal directly connected 
via a 327x cluster-controller to the mainframe. The Mail 
option is selected from a menu and the interface is 
limited to text. 

• PC with Windows and LAN. Primarily a user within the 
General Office, this hardware platform is a 386/486 PC 
with LAN connection and an operating stack of DOS, Windows 
and Attachmate for 3270 connectivity. These users are 
currently either using X.400 E-Mail or are still using IBM 
PROFS via 3270 emulation. 

• PC with DOS and LAN. This is the same type of user as 
above with DOS as the only element of the operating stack. 
Some of the foreign offices and agents fall into this 
category. They communicate by asynchronous modems using 
a proprietary telex-type communication package (i.e, MCI 
Mail, AT&T EasyLink or Sprint Mail) . 

• PC with Windows or DOS and Modem. Vendors, smaller foreign 
offices and managers that are remote have a modem for 
direct connection to the Public Switched telephone Network 
( PSN) . 

• Mac with LAN. Several users within advertising or the 
general office have Mac workstations that use QuickMail 
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and are not connected to the PROFS messaging system, they 
will be provided a gateway to the X.400 backbone. 

• X-Term and/or UNIX Client-Server . These users are 
primarily in the development and technical support areas 
of the general office. Elm is an example of a current E- 
Mail system used on a Unix mailer which is connected to 
PROFS through address translation programs on the host and 
Fibronics interface connections to the network. 

• Wal-Mart Stores. The stores have no E-Mail system, only a 
message drop which literally prints out text on printers 
at the stores. Each store will be connected to the X.400 
backbone separately by implementing local mail servers by 
installing software on the In-Store Processor (ISP) to 
provide mail storage and directory service. The basic idea 
for the stores is to keep E-Mail uncomplicated, so the UA 
will be "simplified" (SUA) with only basic on-line UA 
functions. Installation is not to disrupt any of the 
stores' business operations since they are truly the 
backbone of the company. Typical UAs within a store are 
the various types of managers (i.e.. Store, Department, 
Customer-Service) and some of the clerks. 

• Distribution Centers. Currently using PROFS through 
sessions back to the host, they will migrate to local mail 
servers similar to the stores . 

• Sam's Clubs. These are wholesale distribution membership- 
only clubs. They have a similar computing environment to 
the stores and distribution centers. 

• Vendor's Enterprise Network . The computer systems, 
networks and mail protocols can vary greatly; therefore, 
using an X.400 E-Mail backbone is extremely important 
since many proprietary systems provide interoperability 
and/or connectivity with X.400. Wal-Mart provides MTAs and 
UA software for the vendors so that they can access their 
enterprise messaging system. 

• Fax. Although not currently connected, the basic E-Mail 
idea with respect to fax is to attach a scanned fax image 
to a message to either a recipients' mailbox or their fax 
machine. Similarly, fax images could be received and 
reviewed on graphics UAs and printed. 

Figure 5-1 illustrates a conceptual version of Wal-Mart 's 
Enterprise E-Mail System, some of which is still in 
conceptional phases. It shows the connections of different 
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Wal-Mart divisions across the WAN that need to be connected to 



the X.400 backbone. These areas, some of which are designated 
UAs as identified above, include: 

« Foreign Offices (including foreign purchasing agents) 

• General Office 

• Buyers Decision Support System, 

• Retail Link and EDI (includes the vendors that use these 
applications ) 

• Stores 

• Sam's Clubs 

• Distribution Centers 

• Subsidiaries and Business Partners 

• Remote and/or mobile users 

Starting in the upper left-hand corner, the IBM mainframe 
system with PROFS is shown which is connected by Ethernet to 
the backbone by an SMTP-X.400 gateway. Moving clockwise, the 
Enterprise Messaging System provides Internet connectivity 
with an X.400-SMTP gateway and modem. The gateway also 
ensures firewall protection to the Internet. In the upper 
right-hand corner, foreign agents are connected to the X.400 
backbone with Netware connectivity (which locally connects the 
UA to the MTA) . However, they must access the PSTN (Public- 
Switched Telephone Network) to reach one of the MTAs on the 
backbone. For the vendor partners, with fewer E-Mail users, 
a remote user agent (RUA) uses FTP (file transfer protocol) 
and a modem connection to the PSTN to the X.400 MTA backbone. 
Sam's Clubs and the Stores obtain X.400 backbone connectivity 
through their existing satellite connectivity, a satellite 
Network Hub WAN, and the MTAs that are installed in the In- 
Store and In-Club Processors (ISP and ICP, respectively) . The 
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SUAs as well as a fully functional training UA (TUA) provide 
all UA activities to the associates. The distribution centers 
and the foreign partnership areas connect to the backbone via 
an MTA to the Wal-Mart Network by dedicated T1 lines. 
Finally, in the central backbone area, the bulk of the X.400 
backbone MTAs are illustrated in at least two-level clusters. 
With the 1984 version of the NCR StarPRO Message Central 400 
product, the maximum number of adjacent MTAs allowed is 255. 

2. Wal-Mart 's UA Requirements 

All UAs will comply with X.400 (84) . The primary 

commercial E-Mail package that will be utilized is Enterprise 
Mail from Enterprise Solutions for the following platforms: 

• Icon Interface in MS Windows for 386/486 PC with LAN 

• Icon Interface in MS Windows for 386/486 PC remote 

• Character/Screen based for Asynchronous Terminals with 

serial connect 

• Icon interface in X-Windows for X-Terms . 

The specific X.400 specification requirements must comply 
with the X.411 and X.420 (Interpersonal Messaging System) 
portion of the standard. Refer to Chapter II for a more in- 
depth description of these MHS standards. These functions 
include: Interpersonal Messaging Service, Support for P2 , P3 
protocols , and Originator/ Recipient attributes for 
addressing . 

3. Identification of Wal-Mart 's MTAs 

Wal-Mart has identified the following locations and 
functions for their enterprise's MTAs: 
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• General Office Complex. This MTA will function as the 
central mail server, the master directory server and will 
provide gateways externally. Also in this location, there 
may be additional MTAs which act as local mail servers for 
divisions within the complex or for high use applications. 

• Stores, Clubs and Distribution Centers. Local MTA 
applications will be running on processors within these 
locations. It is estimated that there will be 50 users per 
store and 100 per distribution center. 

• Foreign Offices. Local Unix servers will require the MTA 
software with modem access and a connection to the LAN or 
a direct serial connection (provided by the user) . 

• Subsidiaries, Business Partners, and Large Vendor 
Enterprises. This covers any medium-sized enterprise with 
whom Wal-Mart has significant E-Mail and/or EDI traffic. 
This system would be an MTA and provide gateways to their 
internal E-Mail systems (if not X.400). 

4. Wal-Mart 's MTA Requirements 

Since Wal-Mart is creating a native X.400 backbone, 
all MTAs must meet the requirements as outlined in the CCITT 
X.400 standards. The reference product, NCR StarPro, is the 
Retix Message Server for Unix, and conforms fully to the 
standard. In order to be most efficient and cost effective, 
the MTA is required to reside on an Unix operating system 
which (1) takes advantage of the multi-tasking capabilities 
and (2) shares the hardware resources with other applications, 
the server file system and other mail gateways. 

Similar to the UA requirements, the MTA should provide 
full support of the PI, P2 and P3 protocols (refer to Chapter 
II) . It should provide reliable message store (even though 
Wal-Mart is implementing the 1984 version) and data transfer 
as well as optimized routing and tracking. Although MTA 
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customization is required by Wal-Mart technicians, NCR's 
StarPro will provide administrative tools and servers to 
configure X.400 mail features and network routing, maintaining 
public directories and distribution lists, delivery /non- 
delivery reports, and system error logging. LAN interfaces 
are required for Novell Netware, TCP/IP, and the public data 
networks . 

Finally, public data sharing is required between the 
main mail server's MTA and any other MTA within the 
enterprise. Administration of a public directory for an MTA 
will be handled locally. Eventually, directory 
synchronization will be required conforming to the X.500 
standard . 

D. WHY X. 400/X. 500? 

Wal-Mart wants an enterprise-wide E-Mail system that will 
enable both users and business applications to communicate 
across an application layer, store-and-forward transport 
backbone. The types of business applications the company 
wishes to use on the enterprise-wide E-Mail service include 
office mail for the home office complex in Arkansas, vendor 
mail services for Retail Link and Electronic Data Interchange 
(EDI), and Buyers Decision Support System (BDSS) . The store- 
and-forward aspect of their E-Mail plan will better utilize 
the bandwidth in the company's existing LAN and satellite WAN. 
Additionally, X.400 is the sole representation of the open 
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systems interconnection electronic messaging standard, yet 
another attractive feature. 

Overall, this E-Mail system must be an enabling technology 
that will evolve with the industry improvements and the 
demands for three very big E-Mail service areas: application 
interfaces, administration, and directory services. Wal-Mart 
prefers the CCITT X.400 family of standards since it 
functionally meets their requirements. This X.400 enterprise 
system will provide store-and-f orward messaging within the 
Wal-Mart enterprise. 

E. X. 400 /X. 500 IMPLEMENTATION STRATEGY 

1 . Methodology 

The chronological X.400 implementation for Wal-Mart' s 
enterprise system started with the General Office complex and 
the X.400 backbone. Next, vendors were connected. X.400 
backbone connection for the international areas has begun. 
One is currently up and running; another is on the way. The 
stores and clubs will initially be connected one at a time. 
Then groups of ten stores and/or clubs will be connected. The 
rest will roll-out quickly in larger groups since the 
technicians intend to have the set-up and configuration of the 
MTAs totally automated. The complete installation goal is end 
of second quarter this year, or June 1994. 
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2 . 



Current Status 



The General Office complex is on-line with the X.400 
backbone. Currently NCR's StarPRO is running well (It is a 
Retix Message Server for Unix clone) . Additionally, one 
application is successfully running at this time on the 
backbone . 

F. LESSONS LEARNED THUS FAR 

Although the X.400 backbone installation is not complete, 
Wal-Mart technicians have learned the following lessons thus 
far. First, be cautious of gateways because they generate a 
lot of administrative work such as directory updates, 
synchronization, error-checking for E-Mail routing as well as 
just making sure the mail gets through. The fewer you have, 
the better. 

Second, when investigating products, check into the 
administrative tools that are provided with the product. The 
idea is to NOT require very many people to be highly trained 
specialists . 

Third, quality of the directory and synchronization 
capabilities are also key features to look for when reviewing 
X.400 products. 

Finally, train your people internally before the actual 
implementation with the focus being "what the program can do 
for you" . Ideally, the best training would be no training 
since that would imply a totally seamless integration. 
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G. FUTURE MESSAGING REQUIREMENTS 



Wal-Mart intends to upgrade the X.400 backbone and 
messaging infrastructure with the X.400 (88) version upon 
completion of the current X.400 installation. The technical 
staff is currently looking into the message store 
functionality which is the primary new feature that the 1988 
version offers. 

Although not stated explicitly in either phone interviews 
or Wal-Mart correspondence, the author believes Wal-Mart 
intends to overlay as many application programs over this 
store-and-f orward architecture that they can. As long as the 
application program interfaces (APIs) are compatable with an 
X.400-based architecture, they will provide the broadest, most 
efficient (in terms of moving information quickly to provide 
"better" packages for "better" business decisions) message 
transport system. 
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VI. CONCLUSIONS 



A. BENEFITS OF AN X.400 ENTERPRISE ELECTRONIC MESSAGING 

SYSTEM 

The CCITT X.400 (88) family of standards is a messaging 

transport standard that facilitates international message 
exchange between subscribers to computer-based store-and- 
forward message services. Combined with an appropriate 
network architecture, the series provides a complete package 
for transport of electronic objects which may include 
digitized voice, documents, forms, graphics, images, spread 
sheets and text. Its rival protocol, SMTP, as its name 

implies, is simply providing mostly textual messaging 
capability. 5 In an unprecedented globally competitive market, 
industry demands an electronic mail or messaging system that 
will transport all forms of data. 

B. LESSONS LEARNED FROM INDUSTRY 

Although the X.400 standard in one form or another has 
been around for nearly a decade, those in the corporate world 
that have implemented the standard have compiled a list of 
lessons learned. Assembling an enterprise messaging system 



5 Multiple Internet Mail Extension (MIME) has been proposed as 
an extension of SMTP to allow for all media types in the mail 
envelope . 
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does require a working knowledge of network architecture and 
transport protocols, as well as a full understanding of X.400 
specifications. Although installation time may be enhanced 
with the very best available technical resources (the X.400 
vendors themselves) , it will take more time than anticipated 
to configure each MHS ' s options. Broad knowledge about 
client-server operating systems and mail applications is 
essential during installation. As mentioned previously, the 
following additional guidelines may improve a business's X.400 
implementation : 

• Contract with vendors or reliable third party service 
providers to help with initial design, planning, 
installation and configuration, especially if you don't 
have specific expertise in house. This will pay for itself 
many times over. 

• Train support people so you build expertise in-house and 
can maintain your systems in the long run. 

• Try to minimize the number of vendors involved in the 
construction of your system. For example, it may be a 
better approach to purchase all gateways from one vendor 
rather than individual gateways from each vendor. Many 
companies are consolidating their E-Mail systems so they 
only need to support three or four rather than eight or 
ten . 

• If you purchase equipment from more than one vendor, bring 
them all together at the same time during installation. 
In addition, make sure you ask about interoperability 
testing to ensure that the equipment you are buying 
interoperate. Ask specifically about version numbers and 
system configuration, not just the X.400 system. 

• Watch out for updates and upgrades. Test everything 
before you install. You need to test compatibility all 
over again if one component changes. 

• Backbone designs are usually more efficient to manage than 
point-to-point gateways, as they have fewer interdependent 
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components and less equipment, reducing maintenance 
requirements . 

Finally, evaluate the administrative interface and 
functionality of the systems. It's a demonstrated fact that 
an easy-to-use interface can save valuable time and make 
troubleshooting easier by orders of magnitude. 

C. HOW DOD AGENCIES CAN ACHIEVE X.40 0 FUNCTIONALITY 

DMS is not scheduled for completion until the year 2007. 
The X.400 messaging portion may be implemented as soon as the 
year 2000. In the interim, with the basic premise that 
X.400/X.500 standards will be useful for any DoD component to 
incorporate into their communications architecture, components 
may obtain X.400/X.500 services/functionality by using any 
one or a combination of the methods mentioned in Chapter III. 
It is important to note that these methods are strictly 
conceptual and would rely on a case-by-case, thorough 
requirements analysis (including a review of any existing 
contracts) prior to any implementation plan. The following 
conceptual scenarios are provided. 

For agencies that are light on mail traffic, public E-mail 
providers such as AT&T, MCI and Sprint are most cost effective 
since installation costs are low and the providers take on the 
burden of integration and management issues. Public E-mail 
providers are the fastest and simplest way to set up X.400 
connectivity. The agency would "subscribe" to a messaging 
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service paying a set-up charge and a "per message" charge 
based on usage. The public providers usually include set-up, 
configuration, maintenance and support as part of the service. 
In addition to messaging, they also provide enhanced services 
like accounting and monitoring. 

For agencies that know they will be a big player in the 
DMS program, i.e., they have a large-volume messaging 
requirement or their mission is operationally critical to 
National Defense, the Wal-Mart implementation provides a good 
example of how to build an X.400 backbone on an already- 
existing enterprise-wide network and telecommunication 
infrastructure (Refer to Chapter V) . Basically, the DoD 
component would need to purchase the hardware and software 
needed to build a native, in-house, X.400 enterprise system. 
The advantages of this strategy include complete control over 
the E-mail system, its security and performance. 
Additionally, it offers better integration with existing 
corporate computing and data processing functions than public 
link or strictly proprietary services do. As Chapter V points 
out, there are a number of vendors such as DEC and HP that 
provide all the components needed for storing and routing 
X.400 messages. 

Finally, agencies that (1) have a number of E-Mail 
packages that currently can't talk to one another (or it's 
"addressingly " very painful for them to), and (2) are 
connected on a LAN or WAN, need a series of gateways. Most 
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PC-based E-Mail vendors and minicomputer and mainframe 
computer messaging systems have X.400 gateways between their 
proprietary messaging systems and X.400. If any of the E-Mail 
packages do not provide X.400 connectivity, the DoD component 
may have to procure another vendor's compatible X.400 gateway 
product. For example, a number of third-party vendors such 
as Retix, DEC, World Talk and Soft-Switch provide X.400 
gateways and/or servers for connecting dissimilar messaging 
services. These products support not only a wide selection of 
proprietary protocols but also provide the message handling 
agents (UAs and MTAs ) required for sending X.400 messages. 
Some of these products include directory services that tie 
together dissimilar E-mail directory formats. If the agency 
has strictly LAN electronic messaging requirements, they will 
not need a gateway for UA and MTA conversion; but, it is 
highly unlikely for an agency to have strictly local messaging 
requirements . The LAN E-Mail market is dominated by Lotus 
Development Corp.'s cc:Mail, Microsoft Corp.'s Microsoft Mail 
and WordPerfect Corp.'s WordPerfect Office, in that order. 
Their specific attributes are listed in Chapter III. 

D. SUMMARY 

Creating a global messaging standard that transparently 
unites all disparate E-Mail systems is both laudable and 
possible with X.400 and its directory counterpart, X.500. 
This thesis provided technicians and managers alike who are 
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associated with an E-Mail system with a basic, thorough 
discussion of the CCITT X.400 family of Message Handling 
Standards and a brief definition of the associated CCITT X.500 
Directory standard. Implementation issues were extensively 
discussed and illustrated using published technical reports. 
Showing the broad scope of these standards, examples from both 
DoD and industry were provided. Within DoD, native X.400 is 
required as part of the E-Mail portion of the global Defense 
Message System. Within industry, X.400 is required for 
international companies to maintain a competitive edge as 
shown through a very successful retail store's current X.400 
implementation, Wal-Mart Stores Inc. 
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APPENDIX ACRONYMS 



AAME 


Automated Multi-Media Exchange 


ADI 


AUTODIN- to -DISN Interface 


admd 


administrative management domain 


AFAMPE 


Air Force Automated Message Processing Exchange 


AIA 


Aerospace Industry Association 


AMHS 


Automated Message Handling System 


AMPE 


Automated Message Processing Exchange and 



Telephony 



API 


Application Program Interface 


ARPANET 


Advanced Research Projects Agency Network 


ASC 


AUTODIN Switching Center 


ASD 


Assistant Secretary of Defense 


AU 


Access Unit 


AUTODIN 


Automatic Digital Network 


C3I 


Command, Control, Communications, and Intelligence 


CCITT 


Consultative Committee on International Telegraphy 


CSP 


Communication Support Processor 


DARPA 


Defense Advanced Research Agency 


DDN 


Defense Data Network 


DEC 


Digital Equipment Corporation 
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DIR 


Directory 


DISA 


Defense Information Systems Agency 


DISN 


Defense Information System Network 


DMS 


Defense Message System 


DMSWG 


Defense Message System Working Group 


DoD 


Department of Defense 


DPI 


Data Processing Installation 


DSNET 


Defense Secure Network 


EDI 


Electronic Data Interchange 


FTP 


File Transfer Protocol 


GOSIP 


Government Open System Interconnection Profile 


HP 


Hewlett Packard 


ICP 


In-Club Processor (Wal-Mart) 


IFIP 


International Federation of Information Processing 


IP 


Internet Protocol 


IS 


Information Systems 


ISP 


In-Store Processor (Wal-Mart) 


LAN 


Local Area Network 


LDMX 


Local Digital Message Exchange 


Mac 


Macintosh 
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MHS 


Message Handling System 


MILNET 


Military Network 


MIS 


Management Information Systems 


MROC 


Multi-command Required Operational Capability 


MS 


Message Store 


MSP 


Message Security Protocol 


MTA 


Message Transfer Agent 


MTS 


Message Transfer System 


NIC 


Network Information Center 


OAS 


Office Automation System 


OSI 


Open System Interconnection 


OUA 


Organizational User Agent 


PLA 


Plain Language Address 


PMSP 


Preliminary Message Security Protocols 


prmd 


private management domain 


PSTN 


Packet-Switched Telephone Network 


RFP 


Request For Proposal 


RI 


Routing Indicator 


RTS 


Reliable Transport Services 


RUA 


Remote User Agent (Wal-Mart) 


SDNS 


Secure Data Network System 
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SMTP 


Simple Mail Transfer Protocol 


SUA 


Simplified User Agent (Wal-Mart) 


TAIS 


Target Architecture and Implementation Strategy 


TCC 


Telecommunication Center 


TCP 


Transmission Control Protocol 


TELEX 


Telephone Exchange 


TPN 


Tactical Packet-switched Network 


TUA 


Training User Agent (Wal-Mart) 


UA 


User Agent 


UNESCO 


United Nations Educational Scientific and Cultural 


WAN 


Wide Area Network 


XAPIA 


X.400 Application Program Interface Association 
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